Interrupts in a graphical programming system

ABSTRACT

System and method for using interrupts in a graphical programming system. A graphical program (GP) comprising a plurality of interconnected nodes which visually indicate functionality of the program is stored on a host computer, where the GP is executable to access a device. The GP and an interrupt service routine (ISR) may be created in response to user input, and if created on another computer system, deployed to the host computer. The GP includes program instructions, e.g., an ISR registration node, e.g., generated and/or included in response to user input, which are executable to register the ISR, and may also include an ISR node representing the ISR. The ISR is stored, and the GP executed, including registering the ISR with the host computer and executing the ISR in response to an interrupt from the device, including acknowledging/clearing the interrupt, and invoking a function, e.g., by invoking an interrupt service thread.

PRIORITY DATA

This application claims benefit of priority of U.S. ProvisionalApplication Ser. No. 60/602,215 titled “Interrupts In A GraphicalProgramming System”, filed Aug. 17, 2004, whose inventors were Philip G.Carmichael and Andrew P. Dove.

FIELD OF THE INVENTION

The present invention relates to the field of graphical programming, andmore particularly to a system and method for using interrupts in agraphical programming system.

DESCRIPTION OF THE RELATED ART

Traditionally, high level text-based programming languages have beenused by programmers in writing application programs. Many different highlevel text-based programming languages exist, including BASIC, C, C++,Java, FORTRAN, Pascal, COBOL, ADA, APL, etc. Programs written in thesehigh level text-based languages are translated to the machine languagelevel by translators known as compilers or interpreters. The high leveltext-based programming languages in this level, as well as the assemblylanguage level, are referred to herein as text-based programmingenvironments.

Increasingly, computers are required to be used and programmed by thosewho are not highly trained in computer programming techniques. Whentraditional text-based programming environments are used, the user'sprogramming skills and ability to interact with the computer systemoften become a limiting factor in the achievement of optimal utilizationof the computer system.

There are numerous subtle complexities which a user must master beforehe can efficiently program a computer system in a text-basedenvironment. The task of programming a computer system to model orimplement a process often is further complicated by the fact that asequence of mathematical formulas, steps or other procedures customarilyused to conceptually model a process often does not closely correspondto the traditional text-based programming techniques used to program acomputer system to model such a process. In other words, the requirementthat a user program in a text-based programming environment places alevel of abstraction between the user's conceptualization of thesolution and the implementation of a method that accomplishes thissolution in a computer program. Thus, a user often must substantiallymaster different skills in order to both conceptualize a problem orprocess and then to program a computer to implement a solution to theproblem or process. Since a user often is not fully proficient intechniques for programming a computer system in a text-based environmentto implement his solution, the efficiency with which the computer systemcan be utilized often is reduced.

To overcome the above shortcomings, various graphical programmingenvironments now exist which allow a user to construct a graphicalprogram or graphical diagram, also referred to as a block diagram. U.S.Pat. Nos. 4,901,221; 4,914,568; 5,291,587; 5,301,301; and 5,301,336;among others, to Kodosky et al disclose a graphical programmingenvironment which enables a user to easily and intuitively create agraphical program. Graphical programming environments such as thatdisclosed in Kodosky et al can be considered a higher and more intuitiveway in which to interact with a computer. A graphically basedprogramming environment can be represented at a level above text-basedhigh level programming languages such as C, Basic, Java, etc.

A user may assemble a graphical program by selecting various icons ornodes which represent desired functionality, and then connecting thenodes together to create the program. The nodes or icons may beconnected by lines representing data flow between the nodes, controlflow, or execution flow. Thus the block diagram may include a pluralityof interconnected icons such that the diagram created graphicallydisplays a procedure or method for accomplishing a certain result, suchas manipulating one or more input variables and/or producing one or moreoutput variables. In response to the user constructing a diagram orgraphical program using the block diagram editor, data structures and/orprogram instructions may be automatically constructed which characterizean execution procedure that corresponds to the displayed procedure. Thegraphical program may be compiled or interpreted by a computer.

A graphical program may have a graphical user interface. For example, increating a graphical program, a user may create a front panel or userinterface panel. The front panel may include various graphical userinterface elements or front panel objects, such as user interfacecontrols and/or indicators, that represent or display the respectiveinput and output that will be used by the graphical program, and mayinclude other icons which represent devices being controlled.

Thus, graphical programming has become a powerful tool available toprogrammers. Graphical programming environments such as the NationalInstruments LabVIEW product have become very popular. Tools such asLabVIEW have greatly increased the productivity of programmers, andincreasing numbers of programmers are using graphical programmingenvironments to develop their software applications. In particular,graphical programming tools are being used for test and measurement,data acquisition, process control, man machine interface (MMI),supervisory control and data acquisition (SCADA) applications, modeling,simulation, image processing/machine vision applications, motioncontrol, and embedded applications, among others.

Many programs, e.g., driver software, require, or may benefit from, theuse of interrupts, where an interrupt refers to a signal that informs aprogram that an event has occurred. Generally, when a program receivesan interrupt signal, it responds by performing a specified function oraction, typically by temporarily suspending its normal processing toservice the interrupt. Interrupts (interrupt signals) may originate froma variety of sources. For example, hardware interrupts include keystrokeinterrupt signals from keyboards, and interrupts from other devices,such as printers, indicating that some event has occurred. Softwareinterrupts are interrupt signals initiated by programs, and are alsoreferred to as traps or exceptions.

Interrupts are typically written in C and assembly, and are generallyregistered with the operating system, where the details of how thishappens vary depending on the OS/platform. However, implementation anduse of interrupts is not generally supported in prior art graphicalprogramming systems.

SUMMARY OF THE INVENTION

One embodiment of the present invention comprises a system and methodfor creating, registering, and using interrupts in a graphicalprogramming system. The following describes a method for creating agraphical program utilizing interrupts, according to one embodiment.

First, a graphical program may be stored, e.g., on host computer system,on a different computer system, or on another host device, each of whichmay be referred to as a host computer, where the graphical program isexecutable to access a device, such as, for example, instrumentation andcontrol devices, including but not limited to: a GPIB instrument andassociated GPIB interface card, a data acquisition board and associatedsignal conditioning circuitry, a VXI instrument, a PXI instrument, avideo device or camera and associated image acquisition (or machinevision) card, a motion control device and associated motion controlinterface card, and/or one or more computer based instrument cards, afieldbus device and associated fieldbus interface card, a PLC(Programmable Logic Controller), a serial instrument and associatedserial interface card, or a distributed data acquisition system, such asthe Fieldpoint system available from National Instruments, among othertypes of devices.

The graphical program may be created or assembled by the user arrangingon a display a plurality of nodes or icons and then interconnecting thenodes to create the graphical program, e.g., in a graphical programmingdevelopment environment, such as LabVIEW, provided by NationalInstruments Corporation. In response to the user assembling thegraphical program, data structures may be created and stored whichrepresent the graphical program. The nodes may be interconnected in oneor more of a data flow, control flow, or execution flow format. Thegraphical program may thus comprise a plurality of interconnected nodesor icons which visually indicates the functionality of the program. Thegraphical program also preferably includes a plurality of data elements,e.g., data structures, such as arrays, clusters, objects (e.g.,instantiated from classes), and so forth.

The graphical program may comprise a block diagram and may also includea user interface portion or front panel portion. Where the graphicalprogram includes a user interface portion, the user may optionallyassemble the user interface on the display. As one example, the user mayuse the LabVIEW graphical programming development environment to createthe graphical program. The graphical program may implement a measurementfunction or any other type of function that is desired to be performedby the instrument.

An interrupt service routine (ISR) may be stored, e.g., on the hostcomputer. The ISR may be created in response to user input. For example,in one embodiment, creating the graphical program may comprise includingan ISR node in the graphical program in response to user input, wherethe ISR node represents the interrupt service routine (ISR). The ISRnode may include text-based program code, or may be implemented entirelyin a graphical programming language, such as the “G” graphicalprogramming language of the LabVIEW environment.

In one embodiment, creating the graphical program may include displayinga configuration graphical user interface (GUI) in response to userinput, receiving user input to the configuration GUI specifying the ISR,and programmatically generating the program instructions implementingthe ISR in response to the specifying. In other words, the user maycreate the ISR manually, or via a development tool that may be operableto programmatically generate the ISR based on user input.

For example, the user may create the ISR as a callable node, referred toas a subVI in the LabVIEW system, and may include or associate programinstructions, e.g., in C or some other text-based programming language,with the node. Alternatively, the user may write a graphical programimplementing the ISR, referred to as a VI in the LabVIEW system, and mayassociate or represent the ISR with the ISR node, e.g., as a subVI.

In embodiments where the graphical program is created on a differentcomputer system than the host computer, the method may include deployingthe graphical program and the ISR to the host computer.

The graphical program may be executed, e.g., to perform thefunctionality specified by the user. For example, the graphical programmay be executed in response to user input invoking execution of theprogram, e.g., from an integrated development environment (IDE), such asLabVIEW, executing on the host computer. In another embodiment, thegraphical program may be deployed to another hardware device, e.g., anembedded device, and execution initiated by user input to the embeddeddevice, by user input received to a front panel on a host device, e.g.,computer system, or automatically, e.g., upon deployment to the embeddeddevice.

Executing the graphical program may include registering the ISR. Theregistration may be specified and performed in a variety of differentways. For example, the graphical program may include programinstructions, e.g., graphical or text-based, that are executable toperform the registration of the ISR. Thus, in one embodiment, creatingthe graphical program may comprise including program instructions in thegraphical program which are executable to register the ISR. For example,including program instructions in the graphical program may compriseincluding an ISR registration node in the graphical program in responseto user input, e.g., by the user “dragging and dropping” the ISRregistration node into the graphical program, i.e., onto a block diagramof the graphical program. The ISR registration node may then beexecutable to perform the registration, i.e., as part of the executionof the graphical program. In an embodiment where the graphical programis converted to a text-based form for execution, the method may includegenerating text-based program instructions based on the ISR registrationnode, where the text-based program instructions are executable toperform the registration.

In other embodiments, including the program instructions in thegraphical program for registering the ISR may include displaying aconfiguration graphical user interface (GUI) in response to user input,receiving user input to the configuration GUI specifying registration ofthe ISR, and generating the program instructions in the graphicalprogram in response to the specifying. In other words, the user mayspecify the registration via a GUI, such as a wizard or configurationprogram, and corresponding program instructions (either text-based orgraphical source code) may be automatically generated and included inthe graphical program. Note that in various embodiments, the generatedcode may be visible to the user (e.g., the ISR registration node may beprogrammatically inserted into the graphical program), or may not bevisible to the user (e.g., the program instructions may “underlie” thegraphical program nodes). In one embodiment, registering the ISR mayinclude loading a function pointer for the ISR into a register of thehost computer.

Finally, the (registered) ISR may execute in response to an interruptfrom the device. In other words, during execution of the graphicalprogram, the device may generate an interrupt. The ISR may then receiveor intercept the interrupt, and execute in response. For example, in anembodiment where the ISR was registered by loading a function pointerfor the ISR into a register of the host computer, the loaded functionpointer may be used to invoke the ISR to “handle” the interrupt.

In some embodiments, executing the ISR in response to an interrupt fromthe device may include executing the ISR to perform one or more of:acknowledging the interrupt, clearing the interrupt, and invoking afunction. For example, in one embodiment, invoking a function mayinclude invoking an interrupt service thread, e.g., where the interruptservice thread is specifically for processing functions related tointerrupts. It should be noted that the ISR may perform any type offunction as desired, including doing nothing at all, i.e., ignoring theinterrupt. For example, in some embodiments, the ISR may include anyfunctionality for handling the request itself, or may invoke otherfunctions, as noted above.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention can be obtained when thefollowing detailed description of the preferred embodiment is consideredin conjunction with the following drawings, in which:

FIG. 1A illustrates a computer system operable to execute a graphicalprogram according to an embodiment of the present invention;

FIG. 1B illustrates a network system comprising two or more computersystems that may implement an embodiment of the present invention;

FIG. 2A illustrates an instrumentation control system according to oneembodiment of the invention;

FIG. 2B illustrates an industrial automation system according to oneembodiment of the invention;

FIG. 3A is a high level block diagram of an exemplary system which mayexecute or utilize graphical programs;

FIG. 3B illustrates an exemplary system which may perform control and/orsimulation functions utilizing graphical programs;

FIG. 4 is an exemplary block diagram of the computer systems of FIGS.1A, 1B, 2A and 2B and 3B;

FIG. 5 is a flowchart diagram illustrating one embodiment of a methodfor implementing and using interrupts in a graphical program;

FIG. 6 illustrates an example ISR registration API, according to oneembodiment;

FIGS. 7 and 8 illustrate example use cases for interrupt handling withan ISR, according to one embodiment;

FIG. 9 illustrates traditional vs. ISR paths for interrupt handling,according to one embodiment; and

FIG. 10-12 illustrate one embodiment of a graphical user interface forspecifying and configuring an interrupt service routine (ISR), accordingto one embodiment.

While the invention is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and are herein described in detail. It should beunderstood, however, that the drawings and detailed description theretoare not intended to limit the invention to the particular formdisclosed, but on the contrary, the intention is to cover allmodifications, equivalents and alternatives falling within the spiritand scope of the present invention as defined by the appended claims.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Incorporation by Reference

The following references are hereby incorporated by reference in theirentirety as though fully and completely set forth herein:

U.S. Provisional Application Ser. No. 60/602,215 titled “Interrupts In AGraphical Programming System”, filed August 17.

U.S. Pat. No. 4,914,568 titled “Graphical System for Modeling a Processand Associated Method,” issued on Apr. 3, 1990.

U.S. Pat. No. 5,481,741 titled “Method and Apparatus for ProvidingAttribute Nodes in a Graphical Data Flow Environment”.

U.S. Pat. No. 6,173,438 titled “Embedded Graphical Programming System”filed Aug. 18, 1997.

U.S. Pat. No. 6,219,628 titled “System and Method for Configuring anInstrument to Perform Measurement Functions Utilizing Conversion ofGraphical Programs into Hardware Implementations,” filed Aug. 18, 1997.

U.S. Patent Application Publication No. 20010020291 (Ser. No.09/745,023) titled “System and Method for Programmatically Generating aGraphical Program in Response to Program Information,” filed Dec. 20,2000, currently pending.

Terms

The following is a glossary of terms used in the present application:

Memory Medium—Any of various types of memory devices or storage devices.The term “memory medium” is intended to include an installation medium,e.g., a CD-ROM, floppy disks 104, or tape device; a computer systemmemory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM,Rambus RAM, etc.; or a non-volatile memory such as a magnetic media,e.g., a hard drive, or optical storage. The memory medium may compriseother types of memory as well, or combinations thereof. In addition, thememory medium may be located in a first computer in which the programsare executed, or may be located in a second different computer whichconnects to the first computer over a network, such as the Internet. Inthe latter instance, the second computer may provide programinstructions to the first computer for execution. The term “memorymedium” may include two or more memory mediums which may reside indifferent locations, e.g., in different computers that are connectedover a network.

Carrier Medium—a memory medium as described above, as well as signalssuch as electrical, electromagnetic, or digital signals, conveyed via acommunication medium such as a bus, network and/or a wireless link.

Programmable Hardware Element—includes various types of programmablehardware, reconfigurable hardware, programmable logic, orfield-programmable devices (FPDs), such as one or more FPGAs (FieldProgrammable Gate Arrays), or one or more PLDs (Programmable LogicDevices), such as one or more Simple PLDs (SPLDs) or one or more ComplexPLDs (CPLDs), or other types of programmable hardware. A programmablehardware element may also be referred to as “reconfigurable logic”.

Medium—includes one or more of a memory medium, carrier medium, and/orprogrammable hardware element; encompasses various types of mediums thatcan either store program instructions/data structures or can beconfigured with a hardware configuration program. For example, a mediumthat is “configured to perform a function or implement a softwareobject” may be 1) a memory medium or carrier medium that stores programinstructions, such that the program instructions are executable by aprocessor to perform the function or implement the software object; 2) amedium carrying signals that are involved with performing the functionor implementing the software object; and/or 3) a programmable hardwareelement configured with a hardware configuration program to perform thefunction or implement the software object.

Program—the term “program” is intended to have the full breadth of itsordinary meaning. The term “program” includes 1) a software programwhich may be stored in a memory and is executable by a processor or 2) ahardware configuration program useable for configuring a programmablehardware element.

Software Program—the term “software program” is intended to have thefull breadth of its ordinary meaning, and includes any type of programinstructions, code, script and/or data, or combinations thereof, thatmay be stored in a memory medium and executed by a processor. Exemplarysoftware programs include programs written in text-based programminglanguages, such as C, C++, Pascal, Fortran, Cobol, Java, assemblylanguage, etc.; graphical programs (programs written in graphicalprogramming languages); assembly language programs; programs that havebeen compiled to machine language; scripts; and other types ofexecutable software. A software program may comprise two or moresoftware programs that interoperate in some manner.

Hardware Configuration Program—a program, e.g., a netlist or bit file,that can be used to program or configure a programmable hardwareelement.

Graphical Program—A program comprising a plurality of interconnectednodes or icons, wherein the plurality of interconnected nodes or iconsvisually indicate functionality of the program.

The following provides examples of various aspects of graphicalprograms. The following examples and discussion are not intended tolimit the above definition of graphical program, but rather provideexamples of what the term “graphical program” encompasses:

The nodes in a graphical program may be connected in one or more of adata flow, control flow, and/or execution flow format. The nodes mayalso be connected in a “signal flow” format, which is a subset of dataflow.

Exemplary graphical program development environments which may be usedto create graphical programs include LabVIEW, DasyLab, DiaDem andMatrixx/SystemBuild from National Instruments, Simulink from theMathWorks, VEE from Agilent, WiT from Coreco, Vision Program Managerfrom PPT Vision, SoftWIRE from Measurement Computing, Sanscript fromNorthwoods Software, Khoros from Khoral Research, SnapMaster from HEMData, Vis Sim from Visual Solutions, ObjectBench by SES (Scientific andEngineering Software), and VisiDAQ from Advantech, among others.

The term “graphical program” includes models or block diagrams createdin graphical modeling environments, wherein the model or block diagramcomprises interconnected nodes or icons that visually indicate operationof the model or block diagram; exemplary graphical modeling environmentsinclude Simulink, SystemBuild, Vis Sim, Hypersignal Block Diagram, etc.

A graphical program may be represented in the memory of the computersystem as data structures and/or program instructions. The graphicalprogram, e.g., these data structures and/or program instructions, may becompiled or interpreted to produce machine language that accomplishesthe desired method or process as shown in the graphical program.

Input data to a graphical program may be received from any of varioussources, such as from a device, unit under test, a process beingmeasured or controlled, another computer program, a database, or from afile. Also, a user may input data to a graphical program or virtualinstrument using a graphical user interface, e.g., a front panel.

A graphical program may optionally have a GUI associated with thegraphical program. In this case, the plurality of interconnected nodesare often referred to as the block diagram portion of the graphicalprogram.

Node—In the context of a graphical program, an element that may beincluded in a graphical program. A node may have an associated icon thatrepresents the node in the graphical program, as well as underlying codeor data that implements functionality of the node. Exemplary nodesinclude function nodes, terminal nodes, structure nodes, etc. Nodes maybe connected together in a graphical program by connection icons orwires.

Data Flow Graphical Program (or Data Flow Diagram)—A graphical programor diagram comprising a plurality of interconnected nodes, wherein theconnections between the nodes indicate that data produced by one node isused by another node.

Graphical User Interface—this term is intended to have the full breadthof its ordinary meaning. The term “Graphical User Interface” is oftenabbreviated to “GUI”. A GUI may comprise only one or more input GUIelements, only one or more output GUI elements, or both input and outputGUI elements.

The following provides examples of various aspects of GUIs. Thefollowing examples and discussion are not intended to limit the ordinarymeaning of GUI, but rather provide examples of what the term “graphicaluser interface” encompasses:

A GUI may comprise a single window having one or more GUI Elements, ormay comprise a plurality of individual GUI Elements (or individualwindows each having one or more GUI Elements), wherein the individualGUI Elements or windows may optionally be tiled together.

A GUI may be associated with a graphical program. In this instance,various mechanisms may be used to connect GUI Elements in the GUI withnodes in the graphical program. For example, when Input Controls andOutput Indicators are created in the GUI, corresponding nodes (e.g.,terminals) may be automatically created in the graphical program orblock diagram. Alternatively, the user can place terminal nodes in theblock diagram which may cause the display of corresponding GUI Elementsfront panel objects in the GUI, either at edit time or later at runtime. As another example, the GUI may comprise GUI Elements embedded inthe block diagram portion of the graphical program.

Front Panel—A Graphical User Interface that includes input controls andoutput indicators, and which enables a user to interactively control ormanipulate the input being provided to a program, and view output of theprogram, while the program is executing.

A front panel is a type of GUI. A front panel may be associated with agraphical program as described above.

In an instrumentation application, the front panel can be analogized tothe front panel of an instrument. In an industrial automationapplication the front panel can be analogized to the MMI (Man MachineInterface) of a device. The user may adjust the controls on the frontpanel to affect the input and view the output on the respectiveindicators.

Graphical User Interface Element—an element of a graphical userinterface, such as for providing input or displaying output. Exemplarygraphical user interface elements comprise input controls and outputindicators

Input Control—a graphical user interface element for providing userinput to a program. Exemplary input controls comprise dials, knobs,sliders, input text boxes, etc.

Output Indicator—a graphical user interface element for displayingoutput from a program. Exemplary output indicators include charts,graphs, gauges, output text boxes, numeric displays, etc. An outputindicator is sometimes referred to as an “output control”.

Interrupt—a signal that informs a program that an event has occurred. Aninterrupt may originate from hardware (a hardware interrupt), or from aprogram (a software interrupt, also known as an exception or trap).

Computer System—any of various types of computing or processing systems,including a personal computer system (PC), mainframe computer system,workstation, network appliance, Internet appliance, personal digitalassistant (PDA), television system, grid computing system, or otherdevice or combinations of devices. In general, the term “computersystem” can be broadly defined to encompass any device (or combinationof devices) having at least one processor that executes instructionsfrom a memory medium.

Measurement Device—includes instruments, data acquisition devices, smartsensors, and any of various types of devices that are operable toacquire and/or store data. A measurement device may also optionally befurther operable to analyze or process the acquired or stored data.Examples of a measurement device include an instrument, such as atraditional stand-alone “box” instrument, a computer-based instrument(instrument on a card) or external instrument, a data acquisition card,a device external to a computer that operates similarly to a dataacquisition card, a smart sensor, one or more DAQ or measurement cardsor modules in a chassis, an image acquisition device, such as an imageacquisition (or machine vision) card (also called a video capture board)or smart camera, a motion control device, a robot having machine vision,and other similar types of devices. Exemplary “stand-alone” instrumentsinclude oscilloscopes, multimeters, signal analyzers, arbitrary waveformgenerators, spectroscopes, and similar measurement, test, or automationinstruments.

A measurement device may be further operable to perform controlfunctions, e.g., in response to analysis of the acquired or stored data.For example, the measurement device may send a control signal to anexternal system, such as a motion control system or to a sensor, inresponse to particular data. A measurement device may also be operableto perform automation functions, i.e., may receive and analyze data, andissue automation control signals in response.

FIG. 1A—Computer System

FIG. 1A illustrates a computer system 82 operable to implement variousembodiments of the present invention. One embodiment of a method forimplementing interrupts in a graphical programming system is describedbelow.

As shown in FIG. 1A, the computer system 82 may include a display deviceoperable to display the graphical program as the graphical program iscreated and/or executed. The display device may also be operable todisplay a graphical user interface or front panel of the graphicalprogram during execution of the graphical program. The graphical userinterface may comprise any type of graphical user interface, e.g.,depending on the computing platform.

The computer system 82 may include a memory medium(s) on which one ormore computer programs or software components according to oneembodiment of the present invention may be stored. For example, thememory medium may store one or more graphical programs which areexecutable to perform the methods described herein. Also, the memorymedium may store a graphical programming development environmentapplication used to create and/or execute such graphical programs. Thememory medium may also store operating system software, as well as othersoftware for operation of the computer system. Various embodimentsfurther include receiving or storing instructions and/or dataimplemented in accordance with the foregoing description upon a carriermedium.

FIG. 1B—Computer Network

FIG. 1B illustrates a system including a first computer system 82 thatis coupled to a second computer system 90. The computer system 82 may beconnected through a network 84 (or a computer bus) to the secondcomputer system 90. The computer systems 82 and 90 may each be any ofvarious types, as desired. The network 84 can also be any of varioustypes, including a LAN (local area network), WAN (wide area network),the Internet, or an Intranet, among others. The computer systems 82 and90 may execute a graphical program in a distributed fashion. Forexample, computer 82 may execute a first portion of the block diagram ofa graphical program and computer system 90 may execute a second portionof the block diagram of the graphical program. As another example,computer 82 may display the graphical user interface of a graphicalprogram and computer system 90 may execute the block diagram of thegraphical program.

In one embodiment, the graphical user interface of the graphical programmay be displayed on a display device of the computer system 82, and theblock diagram may execute on a device 190 connected to the computersystem 82. The device 190 may include a programmable hardware elementand/or may include a processor and memory medium which may execute areal time operating system. In one embodiment, the graphical program maybe downloaded and executed on the device 190. For example, anapplication development environment with which the graphical program isassociated may provide support for downloading a graphical program forexecution on the device in a real time system.

Exemplary Systems

Embodiments of the present invention may be involved with performingtest and/or measurement functions; controlling and/or modelinginstrumentation or industrial automation hardware; modeling andsimulation functions, e.g., modeling or simulating a device or productbeing developed or tested, etc. Exemplary test applications where thegraphical program may be used include hardware-in-the-loop testing andrapid control prototyping, among others.

However, it is noted that the present invention can be used for aplethora of applications and is not limited to the above applications.In other words, applications discussed in the present description areexemplary only, and the present invention may be used in any of varioustypes of systems. Thus, the system and method of the present inventionis operable to be used in any of various types of applications,including the control of other types of devices such as multimediadevices, video devices, audio devices, telephony devices, Internetdevices, etc., as well as general purpose software applications such asword processing, spreadsheets, network control, network monitoring,financial applications, games, etc.

FIG. 2A illustrates an exemplary instrumentation control system 100which may implement embodiments of the invention. The system 100comprises a host computer 82 which connects to one or more instruments.The host computer 82 may comprise a CPU, a display screen, memory, andone or more input devices such as a mouse or keyboard as shown. Thecomputer 82 may operate with the one or more instruments to analyze,measure or control a unit under test (UUT) or process 150.

The one or more instruments may include a GPIB instrument 112 andassociated GPIB interface card 122, a data acquisition board 114 andassociated signal conditioning circuitry 124, a VXI instrument 116, aPXI instrument 118, a video device or camera 132 and associated imageacquisition (or machine vision) card 134, a motion control device 136and associated motion control interface card 138, and/or one or morecomputer based instrument cards 142, among other types of devices. Thecomputer system may couple to and operate with one or more of theseinstruments. The instruments may be coupled to a unit under test (UUT)or process 150, or may be coupled to receive field signals, typicallygenerated by transducers. The system 100 may be used in a dataacquisition and control application, in a test and measurementapplication, an image processing or machine vision application, aprocess control application, a man-machine interface application, asimulation application, or a hardware-in-the-loop validationapplication, among others.

FIG. 2B illustrates an exemplary industrial automation system 160 whichmay implement embodiments of the invention. The industrial automationsystem 160 is similar to the instrumentation or test and measurementsystem 100 shown in FIG. 2A. Elements which are similar or identical toelements in FIG. 2A have the same reference numerals for convenience.The system 160 may comprise a computer 82 which connects to one or moredevices or instruments. The computer 82 may comprise a CPU, a displayscreen, memory, and one or more input devices such as a mouse orkeyboard as shown. The computer 82 may operate with the one or moredevices to a process or device 150 to perform an automation function,such as MMI (Man Machine Interface), SCADA (Supervisory Control and DataAcquisition), portable or distributed data acquisition, process control,advanced analysis, or other control, among others.

The one or more devices may include a data acquisition board 114 andassociated signal conditioning circuitry 124, a PXI instrument 118, avideo device 132 and associated image acquisition card 134, a motioncontrol device 136 and associated motion control interface card 138, afieldbus device 170 and associated fieldbus interface card 172, a PLC(Programmable Logic Controller) 176, a serial instrument 182 andassociated serial interface card 184, or a distributed data acquisitionsystem, such as the Fieldpoint system available from NationalInstruments, among other types of devices.

FIG. 3A is a high level block diagram of an exemplary system which mayexecute or utilize graphical programs. FIG. 3A illustrates a generalhigh-level block diagram of a generic control and/or simulation systemwhich comprises a controller 92 and a plant 94. The controller 92represents a control system/algorithm the user may be trying to develop.The plant 94 represents the system the user may be trying to control.For example, if the user is designing an ECU for a car, the controller92 is the ECU and the plant 94 is the car's engine (and possibly othercomponents such as transmission, brakes, and so on.) As shown, a usermay create a graphical program that specifies or implements thefunctionality of one or both of the controller 92 and the plant 94. Forexample, a control engineer may use a modeling and simulation tool tocreate a model (graphical program) of the plant 94 and/or to create thealgorithm (graphical program) for the controller 92.

FIG. 3B illustrates an exemplary system which may perform control and/orsimulation functions. As shown, the controller 92 may be implemented bya computer system 82 or other device (e.g., including a processor andmemory medium and/or including a programmable hardware element) thatexecutes or implements a graphical program. In a similar manner, theplant 94 may be implemented by a computer system or other device 144(e.g., including a processor and memory medium and/or including aprogrammable hardware element) that executes or implements a graphicalprogram, or may be implemented in or as a real physical system, e.g., acar engine.

In one embodiment of the invention, one or more graphical programs maybe created which are used in performing rapid control prototyping. RapidControl Prototyping (RCP) generally refers to the process by which auser develops a control algorithm and quickly executes that algorithm ona target controller connected to a real system. The user may develop thecontrol algorithm using a graphical program, and the graphical programmay execute on the controller 92, e.g., on a computer system or otherdevice. The computer system 82 may be a platform that supports real timeexecution, e.g., a device including a processor that executes a realtime operating system (RTOS), or a device including a programmablehardware element.

In one embodiment of the invention, one or more graphical programs maybe created which are used in performing Hardware in the Loop (HIL)simulation. Hardware in the Loop (HIL) refers to the execution of theplant model 94 in real time to test operation of a real controller 92.For example, once the controller 92 has been designed, it may beexpensive and complicated to actually test the controller 92 thoroughlyin a real plant, e.g., a real car. Thus, the plant model (implemented bya graphical program) is executed in real time to make the realcontroller 92 “believe” or operate as if it is connected to a realplant, e.g., a real engine.

In the embodiments of FIGS. 2A, 2B, and 3B above, one or more of thevarious devices may couple to each other over a network, such as theInternet. In one embodiment, the user operates to select a target devicefrom a plurality of possible target devices for programming orconfiguration using a graphical program. Thus the user may create agraphical program on a computer and use (execute) the graphical programon that computer or deploy the graphical program to a target device (forremote execution on the target device) that is remotely located from thecomputer and coupled to the computer through a network.

Graphical software programs which perform data acquisition, analysisand/or presentation, e.g., for measurement, instrumentation control,industrial automation, modeling, or simulation, such as in theapplications shown in FIGS. 2A and 2B, may be referred to as virtualinstruments.

FIG. 4—Computer System Block Diagram

FIG. 4 is a block diagram representing one embodiment of the computersystem 82 and/or 90 illustrated in FIGS. 1A and 1B, or computer system82 shown in FIG. 2A or 2B. It is noted that any type of computer systemconfiguration or architecture can be used as desired, and FIG. 4illustrates a representative PC embodiment. It is also noted that thecomputer system may be a general purpose computer system, a computerimplemented on a card installed in a chassis, or other types ofembodiments. Elements of a computer not necessary to understand thepresent description have been omitted for simplicity.

The computer may include at least one central processing unit or CPU(processor) 160 which is coupled to a processor or host bus 162. The CPU160 may be any of various types, including an x86 processor, e.g., aPentium class, a PowerPC processor, a CPU from the SPARC family of RISCprocessors, as well as others. A memory medium, typically comprising RAMand referred to as main memory, 166 is coupled to the host bus 162 bymeans of memory controller 164. The main memory 166 may store thegraphical program operable to implement and utilize interrupts. The mainmemory may also store operating system software, as well as othersoftware for operation of the computer system.

The host bus 162 may be coupled to an expansion or input/output bus 170by means of a bus controller 168 or bus bridge logic. The expansion bus170 may be the PCI (Peripheral Component Interconnect) expansion bus,although other bus types can be used. The expansion bus 170 includesslots for various devices such as described above. The computer 82further comprises a video display subsystem 180 and hard drive 182coupled to the expansion bus 170.

As shown, a device 190 may also be connected to the computer. The device190 may include a processor and memory which may execute a real timeoperating system. The device 190 may also or instead comprise aprogrammable hardware element. The computer system may be operable todeploy a graphical program to the device 190 for execution of thegraphical program on the device 190. The deployed graphical program maytake the form of graphical program instructions or data structures thatdirectly represents the graphical program. Alternatively, the deployedgraphical program may take the form of text code (e.g., C code)generated from the graphical program. As another example, the deployedgraphical program may take the form of compiled code generated fromeither the graphical program or from text code that in turn wasgenerated from the graphical program.

FIG. 5—Method for Implementing and Using Interrupts in a GraphicalProgramming System

FIG. 5 illustrates a method for creating a graphical program utilizinginterrupts, according to one embodiment. The method shown in FIG. 5 maybe used in conjunction with any of the computer systems or devices shownin the above Figures, among other devices. In various embodiments, someof the method elements shown may be performed concurrently, in adifferent order than shown, or may be omitted. Additional methodelements may also be performed as desired. As shown, this method mayoperate as follows.

First, as FIG. 5 shows, in 502 a graphical program may be stored, e.g.,on host computer system 82, on a different computer system, or onanother host device, each of which may be referred to as a hostcomputer, where the graphical program is executable to access a device,such as, for example, any of the devices describe above with referenceto FIGS. 2A-3B, among others.

The graphical program may be created or assembled by the user arrangingon a display a plurality of nodes or icons and then interconnecting thenodes to create the graphical program, e.g., in a graphical programmingdevelopment environment, such as LabVIEW, provided by NationalInstruments Corporation. Further details regarding creation of agraphical program are provided below. In response to the user assemblingthe graphical program, data structures may be created and stored whichrepresent the graphical program. The nodes may be interconnected in oneor more of a data flow, control flow, or execution flow format. Thegraphical program may thus comprise a plurality of interconnected nodesor icons which visually indicates the functionality of the program. Thegraphical program also preferably includes a plurality of data elements,e.g., data structures, such as arrays, clusters, objects (e.g.,instantiated from classes), and so forth.

As noted above, the graphical program may comprise a block diagram andmay also include a user interface portion or front panel portion. Wherethe graphical program includes a user interface portion, the user mayoptionally assemble the user interface on the display. As one example,the user may use the LabVIEW graphical programming developmentenvironment to create the graphical program.

In an alternate embodiment, the graphical program may be created in 502by the user creating or specifying a prototype, followed by automatic orprogrammatic creation of the graphical program from the prototype. Thisfunctionality is described in U.S. patent application Ser. No.09/587,682 titled “System and Method for Automatically Generating aGraphical Program to Perform an Image Processing Algorithm”, which ishereby incorporated by reference in its entirety as though fully andcompletely set forth herein. The graphical program may be created inother manners, either by the user or programmatically, as desired. Thegraphical program may implement a measurement function or any other typeof function that is desired to be performed by the instrument.

In 504, an interrupt service routine (ISR) may be stored, e.g., on thehost computer of 502. The ISR may be created in response to user input.For example, in one embodiment, creating the graphical program maycomprise including an ISR node in the graphical program in response touser input, where the ISR node represents the interrupt service routine(ISR). The ISR node may include text-based program code, or may beimplemented entirely in a graphical programming language, such as the“G” graphical programming language of the LabVIEW environment.

In one embodiment, creating the graphical program may include displayinga configuration graphical user interface (GUI) in response to userinput, receiving user input to the configuration GUI specifying the ISR,and programmatically generating the program instructions implementingthe ISR in response to the specifying. In other words, the user maycreate the ISR manually, or via a development tool that may be operableto programmatically generate the ISR based on user input.

For example, the user may create the ISR as a callable node, referred toas a subVI in the LabVIEW system, and may include or associate programinstructions, say, in C or some other text-based programming language,with the node. Alternatively, the user may write a graphical programimplementing the ISR, referred to as a VI in the LabVIEW system, and mayassociate or represent the ISR with the ISR node, e.g., as a subVI.

In embodiments where the graphical program is created on a differentcomputer system than the host computer 82, the method may includedeploying the graphical program and the ISR to the host computer.

In 506, the graphical program may be executed, e.g., to perform thefunctionality specified by the user. For example, the graphical programmay be executed in response to user input invoking execution of theprogram, e.g., from an integrated development environment (IDE), such asLabVIEW, executing on the host computer. In another embodiment, thegraphical program may be deployed to another hardware device, e.g., anembedded device, and execution initiated by user input to the embeddeddevice, by user input received to a front panel on a host device, e.g.,computer system 82, or automatically, e.g., upon deployment to theembedded device.

As FIG. 5 shows, executing the graphical program may include registeringthe ISR, as indicated in 508. The registration may be specified andperformed in a variety of different ways. For example, the graphicalprogram may include program instructions, e.g., graphical or text-based,that are executable to perform the registration of the ISR.

In one embodiment, creating the graphical program may comprise includingprogram instructions in the graphical program which are executable toregister the ISR. For example, including program instructions in thegraphical program may comprise including an ISR registration node in thegraphical program in response to user input, e.g., by the user “draggingand dropping” the ISR registration node into the graphical program,i.e., onto a block diagram of the graphical program. The ISRregistration node may then be executable to perform the registration,i.e., as part of the execution of the graphical program. In anembodiment where the graphical program is converted to a text-based formfor execution, the method may include generating text-based programinstructions based on the ISR registration node, where the text-basedprogram instructions are executable to perform the registration.

In other embodiments, including the program instructions in thegraphical program for registering the ISR may include displaying aconfiguration graphical user interface (GUI) in response to user input,receiving user input to the configuration GUI specifying registration ofthe ISR, and generating the program instructions in the graphicalprogram in response to the specifying. In other words, the user mayspecify the registration via a GUI, such as a wizard or configurationprogram, and corresponding program instructions (either text-based orgraphical source code) may be automatically generated and included inthe graphical program. Note that in various embodiments, the generatedcode may be visible to the user (e.g., the ISR registration node may beprogrammatically inserted into the graphical program), or may not bevisible to the user (e.g., the program instructions may “underlie” thegraphical program nodes).

In one embodiment, registering the ISR may include loading a functionpointer for the ISR into a register of the host computer.

Finally, as FIG. 5 shows, in 510, the (registered) ISR may execute inresponse to an interrupt from the device. In other/words, duringexecution of the graphical program, the device may generate aninterrupt. The ISR may then receive or intercept the interrupt, andexecute in response. For example, in an embodiment where the ISR wasregistered by loading a function pointer for the ISR into a register ofthe host computer, the loaded function pointer may be used to invoke theISR to “handle” the interrupt.

In some embodiments, executing the ISR in response to an interrupt fromthe device may include executing the ISR to perform one or more of:acknowledging the interrupt, clearing the interrupt, and invoking afunction. For example, in one embodiment, invoking a function mayinclude invoking an interrupt service thread (IST), e.g., where theinterrupt service thread is specifically for processing functionsrelated to interrupts. It should be noted that the ISR may perform anytype of function as desired, including doing nothing at all, i.e.,ignoring the interrupt. For example, in some embodiments, the ISR mayinclude any functionality for handling the request itself, or may invokeother functions, as noted above.

Creating the Graphical Program

The following describes one embodiment of a method for creating agraphical program operable to receive and respond to user interfaceevents. It is noted that method elements in the following flowcharts mayoccur concurrently or in different orders than that shown.

A graphical user interface or front panel for the graphical program maybe created, e.g., in response to user input. The graphical userinterface may be created in any of various ways, e.g., depending on thegraphical programming development environment used. A block diagram forthe graphical program may be created. The block diagram may be createdin or using any graphical programming development environment, such asLabVIEW, Simulink, VEE, or another graphical programming developmentenvironment. The block diagram may be created in response to direct userinput, e.g., the user may create the block diagram by placing or“dragging and dropping” icons or nodes on the display andinterconnecting the nodes in a desired fashion. Alternatively, the blockdiagram may be programmatically created from a program specification.The plurality of nodes in the block diagram may be interconnected tovisually indicate functionality of the graphical program. The blockdiagram may have one or more of data flow, control flow, and/orexecution flow representations.

It is noted that the graphical user interface and the block diagram maybe created separately or together, in various orders, or in aninterleaved manner. In one embodiment, the user interface elements inthe graphical user interface or front panel may be specified or created,and terminals corresponding to the user interface elements may appear inthe block diagram in response. For example, when the user places userinterface elements in the graphical user interface or front panel,corresponding terminals may appear in the block diagram as nodes thatmay be connected to other nodes in the block diagram, e.g., to provideinput to and/or display output from other nodes in the block diagram. Inanother embodiment, the user interface elements may be created inresponse to the block diagram. For example, the user may create theblock diagram, wherein the block diagram includes terminal icons ornodes that indicate respective user interface elements. The graphicaluser interface or front panel may then be automatically (or manually)created based on the terminal icons or nodes in the block diagram. Asanother example, the graphical user interface elements may be comprisedin the diagram.

The graphical program may then be executed. The graphical program may beexecuted on any kind of computer system(s) or reconfigurable hardware,as described above. In some embodiments, during execution of thegraphical program, the graphical user interface is displayed on adisplay of a first computer system and the block diagram executes on asecond computer system. As noted above, the graphical program may beoperable to perform any type of functionality specified, including, forexample, one or more of: an industrial automation function, a processcontrol function, and/or a test and measurement function, among others.

Code Generation

In a preferred embodiment, the graphical program may be used to generatea text-based program, which may then be compiled and executed. Forexample, in one embodiment, a C program may be generated based on thegraphical program, e.g., for deployment onto an embedded device. Thus,after the interrupt handler has been implemented in the graphicalprogramming language, a C generator may convert the graphical sourcecode (e.g., interconnected nodes) to C code, although other text-basedlanguages may also be used as desired. Said another way, the method maygenerate program code/objects based on the analysis of 504, where theprogram code/objects may be executable to implement the interruptfunctionality described above.

In some embodiments where code is generated based on the ISR VI, theremay be constraints on the code generation process. For example, in oneembodiment, the generated code may be constrained to be serial withdebugging disabled.

Example Implementation

The following describes a preferred embodiment of an implementation ofthe method of FIG. 5. It should be noted that while the implementationdescribed is in terms of LabVIEW, this is not intended to limit theimplementation to any particular functionality, form, or appearance.Similarly, the methods and techniques disclosed herein may beimplemented for use with any operating systems (OSs) desired, including,for example, Windows, MacOS, Linux, Unix, eCos, and VxWorks, amongothers. Also, while the implementation disclosed below is directed atembedded applications, the techniques described herein may be used forany of various types of execution platforms, including desktop machines,workstations, and portable computing devices, among others.

In one embodiment, a user may write an ISR as a VI, e.g., as a LabVIEWgraphical program. For example, in one embodiment, a developmentenvironment, e.g., an embedded project environment or GUI, may allow auser to create a new “Interrupt Service Routine VI”. The VI may have astrict connector pane (CP) that passes in an interrupt vector and aregistered parameter, where, in the LabVIEW system, a connector panespecifies connectivity between a subVI and front panel elements, e.g.,indicators and controls on the GUI for the VI, and may also specifycommunication between the subVI and its calling parent VI. If a VI isadded as an ISR VI, e.g., via a “New . . . ” dialog or equivalent, thenit may be automatically configured to be an interrupt VI. However, ifthe user wishes to adapt an existing VI to be an ISR, they may simplyconfigure an existing VI, e.g., by selecting a menu item such as“Configure Interrupt VIs”, or equivalent.

In one embodiment, an ISR VI may have the syntax constraints of areentrant-subroutine type without automatic error handling and withadditional diagram syntax constraints. Front panels may not be runtimeviewable and therefore may not be able to respond to user input viacontrols. Diagrams may not be debuggable. As noted above, in someembodiments, an inline C node may be supported in an ISR VI.

Because of ISR VI syntax restrictions, in some embodiments, a per-VIsyntax checking capability may be provided, e.g., in the form ofsubroutine/reentrant checking, and may be flexible enough to accommodateper target differences. For example, in embedded applications, a specialsyntax case may specify that no memory allocations are allowed. In someembodiments, this type of syntax checking may occur at project buildtime, while in other embodiments, the syntax checking may be performedat edit time.

One common use case for ISR VIs is to write the ISR in LabVIEWspecifically to acknowledge the interrupt, and then trigger anoccurrence, where an occurrence refers to a function or functionalityinvoked by the ISR in response to the interrupt. A normal VI may thenwait on the occurrence and do the appropriate hardware interaction. Inthis way, the common interrupt service routine/interrupt service threadmethod of handling interrupts may be maintained.

FIG. 6—ISR Registration

ISRs are traditionally registered and unregistered by device drivers. Asthe drivers are loaded and unloaded, they install and uninstall the ISRroutine with a specific OS application program interface (API). ALabVIEW based API may provided to “install” into the OS. FIG. 6illustrates an example API for registering the ISR, according to oneembodiment. Note that this API is itself graphical, comprising graphicalprogram nodes that may be included in a graphical program, e.g., eithermanually or programmatically.

As shown, FIG. 6 illustrates exemplary nodes for registering the ISR(top node), for unregistering the ISR (middle node), and the ISR itself(bottom node). It should be noted that this API is meant to be exemplaryonly, and is not intended to limit the API to any particular form,function, or appearance.

As described above, in some embodiments, interrupt code restrictions maybe enforced, e.g., to accommodate the particular requirements andconstraints of different execution target platforms. For example,interrupt code restrictions may allow or disallow memory allocation bythe ISR. The allowable operations for an ISR may be a subset of theallowable operations for a subroutine reentrant VI. For example, in someembodiments, the unallowable operations may include asynchronousoperations (File I/O, TCP/IP, Bluetooth, IrDA, etc.), as well as thosethat cause memory allocation (Strings, Arrays, etc.)

In some embodiments, hardware specific or special function registers maybe accessed and/or modified via special code to peek or poke registers.For example, a LabVIEW based VI ISR may access this functionality usingan inline “C” node.

Example Use Cases

Two typical users to contend with when regarding ISR support include:

-   1). An external customer wishing to utilize the support provided for    their hardware; and-   2). An internal or original equipment manufacturer (OEM) customer    wishing to provide support to new hardware.    FIGS. 7 and 8—External Customer Use Cases

FIGS. 7 and 8 illustrate use cases for an external customer. FIG. 7illustrates an example block diagram or graphical program that utilizeswhile loops and occurrences, according to one embodiment.

As FIG. 7 shows, this example block diagram or graphical programincludes an ISR node, indicated by the dark icon with the exclamationmark, and labeled “interrupt.vi”. As may be seen, this node is wired toa registration node, indicated by an “asterisk/exclamation mark” iconwhich may execute to register the ISR at runtime. Note that on the farright of the diagram, a deregistration node is included for disablingthe ISR. Note also that in this example, an interrupt may trigger theISR node, which may trigger an occurrence, shown in the left portion ofthe diagram, and labeled “occurrence”. The occurrence functionality isshown inside the while loop in the right portion of the diagram,represented by a text-code fragment labeled “do IST work here”,referring to the functionality performed by the interrupt servicethread. In other words, this portion of the diagram may include programcode, in this particular case, C code (although the code could also begraphical), which may be invoked and executed on an interrupt servicethread, as mentioned above.

FIG. 8 illustrates an example embodiment where an occurrence is used totrigger the interrupt service thread execution. More specifically, FIG.8 displays the contents of “interrupt.vi” referenced in FIG. 7,according to one embodiment. Note that it is the ISR VI that isregistered to a specific vector. As indicated, FIG. 8 illustrates anexample embodiment where an interrupt is acknowledged and cleared, andin response, an occurrence is used to trigger the IST execution tocomplete the actual work of handling the interrupt.

FIG. 9—Traditional vs. VI Path for ISR/IST

FIG. 9 illustrates high-level path differences between traditionalhandling of interrupts and an approach using graphical programs (e.g.,VIs), according to one embodiment. As FIG. 9 shows, each path beginswith an actual ISR that initiates the sequence of actions in bothapproaches via the OS, which with the ISRs are presumably registered. Inthe traditional (prior art) approach, represented by the top path, anISR function is invoked, which may perform some specified functionality,and which in turn may optionally invoke an interrupt service thread(IST).

The bottom path represents one embodiment corresponding to the methoddescribed above with reference to FIG. 5. As may be seen, in thisapproach an ISR “boilerplate” function may be invoked by the OS. Thisfunction may be provided for users as a basic starting point for theirown “custom” ISR VIs. In other words, basic functionality may beprovided by the boilerplate function, which may in turn invoke the ISRVI, as shown. Note that the boilerplate function may be supplied by anOEM, e.g., specifically for a particular hardware device, and that thisfunction may provide at least minimum necessary functionality to put anISR into an appropriate state or condition to call an ISR, e.g., into astate ready to call a fixed connector pane VI. As FIG. 9 shows, the ISRboilerplate function may invoke an ISR VI, also referred to as an ISR,which may optionally invoke an IST VI to perform a function on an IST.

In one embodiment, if an OEM customer wishes to support ISRfunctionality on their hardware and OS platform, they may implement aset of functions available for use by or in the development environment.For example, in one implementation embodiment, the functions may bestored in a file such as OEM_LVISR.c, or equivalent, which may reside ina platform specific area of a C-Generator runtime library. The functionprototypes may be defined in a corresponding header file, e.g., LVISR.h.

Following this example implementation, the following functions may beprovided:

Boolean InitOEMISRs( );

This routine is preferably not called directly, e.g., is preferably onlycalled by InitISRs, and may be provided by the target vendor. It mayperform any ISR subsystem initialization necessary; and returns TRUE onsuccess, FALSE on failure.

Boolean UninitOEMISRs( );

This routine is preferably not called directly, e.g., is preferably onlycalled by UninitISRs, and may be provided by the target vendor. It mayperform any ISR subsystem cleanup necessary; and returns TRUE onsuccess; FALSE on failure.

Boolean OEMISRRegisterHandler(uInt32 isr_vector,

-   -   uInt32 isr_param,    -   ISRFunc isr_runFunc,    -   uInt32*register_param);

This routine is preferably not called directly, e.g., is preferably onlycalled by ISRRegisterHandler, and may be provided by the target vendor.This routine may perform the actual registration of the interrupt withthe OS or with the hardware (in the case of bare-metal).

In this example, isr_vector is the intended vector, isr_param is theparameter. Both isr_vector and isr_param may be passed to the ISRFuncisr_runFunc. register_param is a parameter that may be used by the OEMroutine to return a parameter specific to this ISR registrationinstance. Upon unregstration of the ISR, the value stored inregister_param may be passed in to the unregister call. This functionreturns TRUE on success, FALSE on failure.

Boolean OEMISRUnregisterHandler(uInt32 isr_vector,

-   -   uInt32 isr_param,    -   ISRFunc isr_runFunc,    -   uInt32 register_param);

This routine is preferably not called directly, e.g., is preferably onlycalled by ISRUnregisterHandler, and may be provided by the targetvendor. It may unregister an ISR at a given vector. The register_parampassed in is the register parameter returned by theOEMISRRegisterHandler routine described above. This function returnsTRUE on success, FALSE on failure.

Note that these functions are presented for example purposes only, andare not intended to limit the techniques and implementations to anyparticular set of functions, functionality, organization, or appearance.

FIGS. 10-12—User Interface

In preferred embodiments, a user interface, e.g., a graphical userinterface (GUI) may be provided for invoking and managing thefunctionality described herein. The following describes one embodimentof such a GUI directed to an embedded application, although it should benoted that the GUI shown is meant to be exemplary only, and is notintended to limit the interface to any particular form, function, orappearance. More specifically, FIGS. 10-12 step through an example userexperience of setting up an interrupt service via a series of dialogs.

As FIG. 10 shows, in this example, the user may create an embeddedproject, e.g., within an IDE, such as LabVIEW, and may implement aninterrupt service routine via a “New . . . ” menu item to add aninterrupt service routine VI (ISR VI). In the embodiment shown, the ISRVI may be similar to a standard VI, but with a specific connector panealready set up. In other words, as mentioned above, the ISR VIscommunication interface may be pre-defined, and may be constant orimmutable. Thus, as shown in FIG. 10, the user has invoked creation ofan ISR VI with the name “MyInterrupt.vi”, and added the VI to the activeproject, where the new VI is located in C:\temp\projs2.

After creating the ISR VI, the VI may be displayed in the embeddedproject file list, as indicated in FIG. 11.

Thus, the ISR VI may be displayed in the project file list as any otherVI in the project. In one embodiment, the user may then select which VIsare configured as interrupt service routines, as shown in FIG. 12. Forexample, the dialog of FIG. 12 may be displayed when the user selects anEmbedded Project menu item “Target->Configure Interrupt VIs”, orequivalent.

At this point, the user may enable and disable interrupts via a staticreference to the ISR VI. For an example of this, refer to theregistration VI portion of the use case described above with referenceto FIG. 7. Note that the user may need to know what interrupt vectorthey need to register, which may depend on the target hardware and OS.

Note that an ISR VI may be configured to be an ISR in various ways. Forexample, in one embodiment, the ISR mode may be an execution priority.In another embodiment, an ISR VI may be a separate VI type specificallyfor interrupt service routines, e.g., denoted by an .vii file extension.

Although the embodiments above have been described in considerabledetail, numerous variations and modifications will become apparent tothose skilled in the art once the above disclosure is fully appreciated.It is intended that the following claims be interpreted to embrace allsuch variations and modifications.

1. A computer-implemented method for handling interrupts in a graphicalprogram, the method comprising: storing a graphical program on a hostcomputer, wherein the graphical program comprises a plurality ofinterconnected nodes which visually indicate functionality of theprogram, and wherein the graphical program is executable to access adevice; storing an interrupt service routine (ISR); and executing thegraphical program, wherein said executing comprises: registering the ISRwith the host computer; and executing the ISR in response to aninterrupt from the device.
 2. The method of claim 1, further comprising:creating the graphical program in response to user input; and creatingthe ISR in response to user input.
 3. The method of claim 2, whereinsaid creating the graphical program and said creating the ISR areperformed on another computer system, the method further comprising:deploying the graphical program and the ISR to the host computer.
 4. Themethod of claim 2, wherein the graphical program comprises programinstructions that are executable to perform said registering the ISR. 5.The method of claim 4, wherein said creating the graphical programcomprises: including the program instructions in the graphical programthat are executable to perform said registering the ISR in response touser input.
 6. The method of claim 5, wherein said including programinstructions in the graphical program comprises: including an ISRregistration node in the graphical program in response to user input. 7.The method of claim 5, wherein said including program instructions inthe graphical program comprises: displaying a configuration graphicaluser interface (GUI) in response to user input; receiving user input tothe configuration GUI specifying registration of the ISR; and generatingthe program instructions in the graphical program in response to saidspecifying.
 8. The method of claim 2, wherein said creating thegraphical program comprises: including an ISR node in the graphicalprogram in response to user input, wherein the ISR node represents theinterrupt service routine (ISR).
 9. The method of claim 8, wherein ISRnode comprises text-based program code.
 10. The method of claim 8,wherein ISR node comprises graphical program code.
 11. The method ofclaim 2, wherein said creating the graphical program comprises:displaying a configuration graphical user interface (GUI) in response touser input; receiving user input to the configuration GUI specifying theISR; and programmatically generating the program instructionsimplementing the ISR in response to said specifying.
 12. The method ofclaim 2, wherein said creating the graphical program comprises:arranging a plurality of nodes on a display; and interconnecting theplurality of nodes in response to user input.
 13. The method of claim 1,wherein said registering the ISR comprises: loading a function pointerfor the ISR into a register of the host computer.
 14. The method ofclaim 1, wherein executing the ISR in response to an interrupt from thedevice comprises executing the ISR to perform: acknowledging theinterrupt; clearing the interrupt; and invoking a function.
 15. Themethod of claim 14, wherein said invoking a function comprises: invokingan interrupt service thread.
 16. The method of claim 1, wherein thegraphical program comprises a block diagram portion and a user interfaceportion.
 16. The method of claim 16, wherein the block diagram portionexecutes on a first computer system, and the user interface portionexecutes on a second computer system coupled to the first computersystem over a network.
 18. The method of claim 1, wherein the graphicalprogram comprises a graphical data flow program.
 19. The method of claim1, wherein the graphical program is operable to perform one or more of:an industrial automation function; a process control function; and atest and measurement function.
 20. The method of claim 19, wherein,during execution of the graphical program, the graphical user interfaceis displayed on a display of a first computer system and the blockdiagram executes on a second computer system.
 21. A memory mediumcomprising program instructions, wherein the program instructions areexecutable by a processor to perform: storing a graphical program,wherein the graphical program comprises a plurality of interconnectednodes which visually indicate functionality of the program, and whereinthe graphical program is executable to access a device; storing aninterrupt service routine (ISR); executing the graphical program,wherein said executing comprises: registering the ISR with the device;and the ISR executing in response to an interrupt from the device.
 22. Asystem for handling interrupts in a graphical program, the systemcomprising: a host computer comprising: a processor; and a memory mediumcoupled to the processor; and a device coupled to the host computer;wherein the memory medium stores: a graphical program, wherein thegraphical program comprises a plurality of interconnected nodes whichvisually indicate functionality of the program, and wherein thegraphical program is executable to access the device; and an interruptservice routine (ISR); wherein the graphical program is executable toregister the ISR with the host computer; wherein the device is operableto generate an interrupt; and wherein the ISR is operable to execute inresponse to the interrupt from the device.
 23. A computer-implementedmethod for handling interrupts in a graphical program, the methodcomprising: storing an interrupt service routine (ISR); storing agraphical program on a host computer, wherein the graphical programcomprises a plurality of interconnected nodes which visually indicatefunctionality of the program, wherein the graphical program comprises afirst node representing the ISR, and wherein the graphical program isexecutable to access a device; and executing the graphical program,wherein said executing the graphical program comprises: registering theISR with the host computer; and executing the first node in response toan interrupt from the device, wherein said executing the first nodecomprises executing the ISR.